AWS Fault Injection Simulator (FIS) の実験でネットワーク接続の中断アクションが利用出来るようになりました

#AWS Fault Injection Simulator

#AWS

いわさ

2022.10.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

本日のアップデートで AWS FIS にてネットワーク接続中断アクションを実行出来るようになりました

これは待望の、AZ 障害を発生させれるやつか？ということで早速試してみました。

アクションが追加

使い方ですが、FIS の実験テンプレートで新しいアクション「aws:network:disrupt-connectivity」が追加されています。
今まではネットワーク障害を注入する際は SSM を使ったシミュレーションを行う方式だったのですが、ネットワーク系の障害注入はなにげに FIS では初めてのようです。

アクションターゲットで指定出来るのはサブネットです。
ターゲットに対して発生時間とスコープを指定することが出来ます。

この記事では ALL による外部トラフィックの遮断と availability-zone による AZ 間通信の遮断をテストしてみました。
他の項目については以下をご確認ください。また prefix-list を指定した場合は prefixListidentifier をオプションとして指定することが出来ます。

オートスケーリンググループ (ASG) 構成の Web アプリケーションに実行

ASG 構成の Web アプリケーションで AZ 障害が発生した場合を再現してみたいと思います。
以下のように東京リージョンの 1a と 1c で 2 台づつインスタンスが起動されている状態です。
ASG のヘルスチェックとしては ELB を設定しています。
EC2 インスタンスステータスだけではなくて ELB からのヘルスチェックリクエストに失敗するケースを想定するためです。

実験テンプレートのターゲットでは 1a のサブネットをターゲットに指定しています。
なお、ここはリソース ID で個別の指定も可能になっています。

実験テンプレートが構成出来たら選択して実験を開始します。

数秒たつと実験の状態が Running になりました。

ターゲットグループの登録済みターゲットの状態を見てみましょう。
1a のインスタンス 2 台が Unhealthy になっていますね。

やがて新しいインスタンスが起動されました。
ただ 1a で起動されていますね。

障害の発生時間は 10 分間を指定しました。
その後も 1a で自動的に新たなインスタンスを起動 → ヘルスチェック失敗を繰り返していました。

実験の終了後はまた 1a で起動出来るようになったので正常なインスタンス 4 台が 2AZ で 2 台づつ起動されている状態に戻りました。

AZ 障害発生時に障害が発生していない AZ で新たなインスタンスが起動される、以下の偏りが発生するパターンを試してみたかったのですが、このアクションでは AZ 障害という扱いにはならないようですね。

AZ 間通信で試してみる

スコープで availability-zone というものもあったのでこちらを使ってみましょう。
このスコープはどの通信障害を発生させるトラフィックを指しているのでこの場合は AZ 間の通信で障害が発生するはずです。

先程の構成で EC2 にセッションマネージャーでリモートアクセスし、別 AZ のインスタンスに ping を実行し続けてみましょう。

sh-4.2$ ping 10.0.2.72
PING 10.0.2.72 (10.0.2.72) 56(84) bytes of data.
64 bytes from 10.0.2.72: icmp_seq=1 ttl=255 time=1.81 ms
64 bytes from 10.0.2.72: icmp_seq=2 ttl=255 time=1.83 ms
64 bytes from 10.0.2.72: icmp_seq=3 ttl=255 time=1.88 ms
64 bytes from 10.0.2.72: icmp_seq=4 ttl=255 time=1.80 ms
64 bytes from 10.0.2.72: icmp_seq=5 ttl=255 time=1.84 ms
64 bytes from 10.0.2.72: icmp_seq=6 ttl=255 time=1.83 ms
64 bytes from 10.0.2.72: icmp_seq=7 ttl=255 time=1.84 ms
64 bytes from 10.0.2.72: icmp_seq=8 ttl=255 time=1.83 ms
64 bytes from 10.0.2.72: icmp_seq=9 ttl=255 time=1.86 ms
64 bytes from 10.0.2.72: icmp_seq=10 ttl=255 time=1.91 ms

上記のように通信が可能ですが、実験開始後は通信ができなくなりました。

ただし、遮断されているのは AZ 間通信のみなので IGW -> ALB -> EC2 の経路は生きている状態で、以下のように外部からのアクセスは可能なままでした。

% curl hoge-web-alb-458003575.ap-northeast-1.elb.amazonaws.com
10.0.3.139
% curl hoge-web-alb-458003575.ap-northeast-1.elb.amazonaws.com
10.0.2.72

さいごに

本日は AWS Fault Injection Simulator (FIS) の実験でネットワーク接続の中断アクションが利用出来るようになったので試してみました。

今まで AZ 障害を再現させたい場合は EC2 の停止をタグポリシーを使った実験を作成するのが FIS では一番近い方法だったと思っているのですが、今回のアクションで特定 AZ のネットワークを遮断する方法も使えそうですね。
完全な AZ 障害というわけではないのでその点は注意が必要ですが、他にもいくつかスコープを絞った使い方が出来るので EC2 以外でも使いやすくなったのではないでしょうか。

ちなみに Aurora のフェイルオーバーが出来るかこのアクションで試してみましたが、それはやはり出来ませんでした。
従来どおり Failover アクションを使うのが良いと思います。